Mobile applications relating to E-commerce, for example, banking and selling applications, require a very high certainty of authentication of the identity of the user. In many cases, the identity of the user and the level of certainty that the user is indeed the one as presented, directly affect the freedom which is given to the user the application owner to perform functionalities while using the application. For example, a user who is known to be reliable, and whose authenticity has been verified in a highest level of certainty may be allowed to perform the full list of functionalities within application, but in another situation, if the authorizing system (which is managed by the owner of the application) faces difficulties in authenticating the same user in the highest level of certainty, the same user may be allowed to perform a limited or null functionalities within the same application. The term “functionalities” may refer, for example, to (a) a permission to access specific data; (b) a permission to store specific data; (c) a permission to purchase a specific product; (d) a permission to perform money transfer; etc. In all said examples different levels of permissions are typically granted to the user based on his credibility, as well as on the level of certainty concluded that the user is indeed the one which is presented.
Typically, when a user tries to access a certain application, for example, to view private information, to make payment, or to file a form, the application needs to determine whether to approve or deny the access. To allow or reject the user's request for performing such an action, the application applies a security policy. A crucial input to this security policy is the defined identity of the user.
To define a user identity, a system manager typically builds a database with respect to each registered user. For each user, the database contains a list of parameters or challenges that must be submitted by the user, such as a username, password, account number, etc. Upon receipt of the user's response and verification against the database, the system either confirms the user's identity and thus grants him the requested permissions, or it denies the request. In some cases, when some level of uncertainty exists with respect to the identity of the user relative to the functionalities he requests to perform, the prior art systems requests the user to fulfill more challenges (such as answering private questions, responding to an SMS which is sent to him, correctly answering a captcha (to determine that he is not a machine), etc. In cases that the authenticity of the user remains in doubt, the prior art systems typically limit the user permissions to perform functionalities that are granted to him.
As noted, the authentication of the user, as well as the grant of permissions to the user to functionalities of the application involves checking of a security policy. The information needed to support a policy decision may be distributed across multiple resources such as databases, directories, risk engines, the user's mobile device or computer, and the application itself. The decision may also be dependent on the ability of the user and/or the application to successfully perform one or more actions, such as authenticating using a specific authenticator, approving a legal disclaimer, or taking a photograph. Such actions may be enforced by multiple enforcement points such as the application itself, the user's mobile device or computer, and other software agents and systems.
The prior art systems for authenticating users of mobile applications and for granting permissions accordingly typically comprise an authentication server at the owner's side (for example, the bank, the selling company, etc.,). The authentication server communicates directly with the respective application at the users' mobile device.
During the recent years, more techniques for authenticating users of mobile applications have become available. Several of said new authentication techniques require the user's intervention (such as a fingerprint module, a camera for conveying the user's face to the remote authentication server, an SMS module for sending SMS to the user, etc.). Other of said authentication techniques are performed in a manner which is transparent to the user (such as verification of the device IP against an expected IP, verification between the user's current location and his expected location, verification of the present behavior of the user, such as, the time of communication against the time in which the same user typically establishes communication, etc.). However, even with the new techniques that are now available there are still fake users that overcome the existing challenges, causing very significant damages to the owner.
In another aspect, security policy requirements pertaining to establish user identities may change based on new security threats, new user experience requirements, and newly developed data repositories and actions. As typically security administrators working (for the owner) at the authentication server side cannot easily modify the applications themselves, they are still required to update in a central manner the respective security policies in order to address new threats, and these updates have to be done in a manner which is transparent to the user.
A user authentication policy may consider and collect many parameters pertaining to the user's identity and the current session with the application. Such evidence parameters may include the following factors:    1. Biometric features of the user such as fingerprints and face structure;    2. The location of the user;    3. The network from which the user accesses the system;    4. The device from which the user accesses the system;    5. The names and types of applications that reside or are activated at the user's device;    6. The type, if at all exists, of an anti-virus protection that exists at the user's device;    7. The one or more mobile operators' platforms on which the user communicates;    8. Whether the communication is made over a secured channel or not;    9. The ability of the user and/or the application to successfully perform one or more challenges; e.g.:            a. Providing a password known to the user        b. Drawing a pattern known to the user            10. The ability of the user to take and send a photograph;    11. Proof that the user is in possession of a device previously associated with him, e.g. by means of:            a. Typing a one-time-password sent to the device;        b. Approving a request securely sent to a specially crafted application;            12. Behavioral characteristics of the user; such as:            a. Typical time-of-day and day-of-week where transactions are executed;            13. The type of transactions that are typically carried out by the user.
In order to comply with said variety of authentication parameters, or authentication means that are introduced, it is necessary to frequently upgrade the mobile application at the user's side. However, each of such upgrade or update of the application to include additional authentication means is a complicated task, that should consider various of security issues, therefore requiring a thorough testing and debugging of the mobile application prior to the upgrade. In some cases, the debugging and testing of an upgraded application to include a new authentication technique may take several months. Such a long period significantly limits the flexibility of the owner in taking urgent measures when new threats are detected, or when the circumstances change for a specific user.
It is therefore an object of the present invention to provide a new structure for authenticating users of mobile applications.
It is another object of the present invention to provide an authentication system which significantly simplifies introductions of new measures for authenticating users of mobile applications.
It is another object of the present invention to significantly shorten the period until updates to an authentication policy of a mobile application can be effected.
It is another object of the present invention to provide an authentication system which enables greater flexibility in defining and effecting amendments to an authentication policy, in a manner which does not require any modification to the mobile application.
Other objects and advantages of the invention will become apparent as the description proceeds.